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15. Bill Presentment 



15.1 Overview 

Bill Presentment (PRES) is the electronic delivery of a bill from a biller to a customer. 

Although some billers may provide Bill Presentment service themselves, many will choose to work with a 
bill publisher that provides Bill Presentment service on behalf of many billers. For this reason, Bill 
Presentment focuses on connecting customers to bill publishers. 

15.1.1 Bill Presentment Model 

This section summarizes the process of receiving bills electronically, starting with the steps required to find 
a bill publisher and set up Bill Presentment service. 

To receive bills electronically, the client: 

1 . Finds one or more billers by searching a biller directory server. 

2. Determines which bill publishers provide Bill Presentment service for the billers. 

3. Enrolls with a bill publisher for Bill Presentment service 

4. Signs on with the bill publisher and activates Bill Presentment service for one or more accounts with 
one or more billers. 

5. Requests electronic bills from the bill publisher. 

6. (Optionally) Pays bills using the Open Financial Exchange Bill Payment service. 

15.1.2 Servers and Message Sets 

During the billing process, the client typically communicates with two Open Financial Exchange servers: 

• Biller directory server: An independent server that stores information about billers and bill publishers. 
Clients can query this server to find the bill publishers that serve the billers in which the customer is 
interested. 

• Bill publisher server: The server that delivers bills to customers. A single bill publisher can provide 
Bill Presentment service for many billers. In some cases, a biller might act as its own bill publisher. 

Although it is possible for a single server to perform both of the functions listed above, it is more likely that 
independent directory servers will provide clients with a single source for finding billers. To allow these 
functions to be routed separately by clients, Bill Presentment defines separate message sets for directory 
query and bill delivery. 

• Biller Directory message set (PRESDIRMSGSETV1) 

• Bill Delivery message set (PRESDLVMSGSETV 1 ) 

For additional information about the message sets defined for Bill Presentment, see section 15.7. 
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15.2 Biller Directory 

To find billers, the client sends a <FINDBILLERRQ> request to the biller directory server. The biller 
directory server returns a <FINDBILLERRS> response. 

<FINDBILLERRQ> and <FINDBILLERRS> are part of the Biller Directory message set 
(PRESDIRMSGSET V 1 ). The message set tags are <PRESDIRMSGSRQV1> and 
<PRESDIRMSGSRSV1>. 

15.2.1 Client Signon to the Biller Directory Server 

Because the client does not enroll with the biller directory server, the client sends a standard signon request 
with dummy values for the user ID and password. Only the basic client identification will be valid. For 
more information about signon requests, refer to Chapter 2 of the Open Financial Exchange specification. 

15.2.2 Search Arguments 

If the client omits all elements in the <FINDBILLERRQ>, the client is requesting a complete directory of 
billers. Otherwise, the client wants to filter results based on the included elements, with strings matched 
case-insensitive using regular expressions' ( for example, is interpreted as a wildcard). 

For each biller that matches the elements in the request, the biller directory server returns the complete 
name and address of the biller, plus the biller ID and bill publisher name. 

15.2.3 Identification of Bill Publishers 

Bill Publishers must be uniquely and consistently identified by name. Clients need some way to relate the 
bill publisher name given by a directory server to their own databases of known and approved bill 
publishers. Since the number of bill publishers is relatively small, and the number of directory servers that 
must be coordinated even smaller, the official corporate name of a bill publisher will serve as an ID for that 
publisher. 

15.2.4 Find Biller Request <FINDBILLERRQ> 

The <FINDBILLERRQ> request must appear within a <FINDBILLERTRNRQ> transaction wrapper. 

Clients that want to receive an updated list of billers and bill publishers can use <DTUPDATE> to avoid 
receiving a response if nothing has changed. <DTUPDATE> is returned by servers in responses to indicate 
the date and time of the newest or most recently changed entry, whether or not it was included in the 
response. Clients performing narrow searches cannot use <DTUPDATE> unless they save the value for 
each query, and send the corresponding value in future requests. 

The name and address fields refer to the biller, except for <CONSUPOSTALCODE> which refers to the 
customer's address. 



1 A regular expression as described by POSIX, a standard developed by IEEE. 
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<FINDBILLERRQ> 

<DTUPDATE> 

<NAME> 

<ADDR1> 

<ADDR2> 

<ADDR3> 

<CITY> 

<STATE> 

<POSTALCODE> 

<COUNTRY> 

<SIC> 

<CONSUPOSTALCODE> 

<INCIMAGES> 
</FINDBILLERRQ> 



Description 



Date and time of last change to any biller entry as reported by 
the server on previous query, datetime. 

Biller's name, regular expression supported, A-32 

Biller's address line 1 , regular expression supported, A-32 

Biller's address line 2, regular expression supported, A-32 

Biller's address line 3, regular expression supported, A-32 

Biller's city, regular expression supported, A-32 

Biller's state, regular expression supported, A-5 

Biller's postal code, regular expression supported, A- 11 

1SO/DIS-3166 3-letter country code standard, A-3 

Standard Industry Code, N-6 

Postal code of customer, to allow server to filter out billers that 
do not do business in the customer's area, A- 11 

Y if the client wants images (logos) returned, Boolean 



15.2.5 Find Biller Response <FINDBILLERRS> 

<FINDBILLERRS> must appear within a <FINDBILLERTRNRS> transaction wrapper. 
The response is a list of <BILLERINFO> aggregates. 



Description 



<FINDBILLERRS> 
<DTUPDATE> 

<BILLERINFO> 
</BILLERINFO> 
</FINDBILLERRS> 



Date and time of last addition or modification to the entries in the 
directory, whether part of this response or not, datetime 

Zero or more <BILLERINFO> aggregates 



15.2.5.1 Biller Information <BILLERINFO> 

<BILLERINFO> includes information about a single biller. 

Besides basic name and address information, <BILLERINFO> includes the <BILLPUB> and 
<BILLERID> elements. These elements will be used with the customer's account number to identify the 
customer's account with the biller. For more information about the account-identification aggregates, refer 
to <PRESACCTFROM> and <PRESACCTTO> in section 15.3.2.2. 

<BILLERINFO> can optionally include elements that specify the format of valid account numbers. 
<ACCTFORMAT> and <ACCTEDITMASK> provide information to the client. <HELPMESSAGE> 
provides a text message that the client can display to the customer. 
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To avoid the complications caused by invalid account numbers, <BILLERINFO> can also include a 
<VALIDATE> URL element that the client application can use to validate the customer's account number. 



1 Tag 


Description 


<BILLERINFO> 




<BILLPUB> 


Official standard name of the bill publisher, A-32 


< -DILLtKlU> 


ID of this biller at this bill publisher, A-12 


<NAME> 


Name of the biller, A-32 


<ADDR1> 


Biller's address line 1, A-32 


<ADDR2> 


Biller's address line 2, A-32 


<ADDR3> 


Biller's address line 3, A-32 


<CITY> 


Biller's city, A-32 


<STATE> 


Biller's state, A-5 


<POSTALCODE> 


Biller's postal code, A-11 


<COUNTRY> 


Biller's country; 3-letter country code from ISO/DIS-3166, A-3 


<SIC> 


otandard Industry Code, N-6 


<PHONE> 


Biller's phone number for customer information (if a special 
number exists for electronic billing information, use that number), 
A-32 


<PAYMPKITIMQTE3I 

^rM T MCIN I IINO I KUlVltlN I 0> 


Types of payment that the biller can accept electronically, see 
section 15.3.5.1 


</PAYMENTINSTRUMENTS> 




<ACCTFORMAT> 


Regular expression describing the account number format, A-255 


<ACCTEDITMASK> 


String describing the edit mask for the account number. The client 
can use the edit mask to assist the user in entering the account 
number, A-255 


<HELPMESSAGE> 


Human-readable message that the client can display to assist the 
customer in entering his or her account number, A-255 


<RESTRICT> 


Human-readable description of any restrictions on who may sign 
up with this biller. A-255 


<LOGO> 


URL of the biller's logo. If the client requested images, the logo 
should be included via multi-part MIME in this response. URL 


<VALIDATE> 


URL for validation. The client application may use this to validate 
the customer's account number. URL 


<BILLERINFOURL> 


URL of human-readable description of additional information the 
biller would like the customer to have with regard to signing up. 
URL 


</BILLERINFO> 
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15.2.6 Status Codes <FINDBILLERTRNRS> 




0 Success (INFO) 

2000 General error (ERROR) 

15.3 Customer Signup 

Once the customer has located a biller and its associated bill publisher, the customer must enroll with the 
bill publisher for Bill Presentment service and activate accounts for one or more billers at that bill 
publisher- 
Bill Presentment uses the standard Open Financial Exchange Signup message set. This section discusses 
only those portions of signup that differ for Bill Presentment. For more information about the Signup 
message set, refer to Chapter 8 of the Open Financial Exchange specification. 

15.3.1 Enrollment 

To enroll with a bill publisher, the client uses the standard Open Financial Exchange enrollment aggregate 
(<ENROLLRQ>). The bill publisher server returns an <ENROLLRS> that provides status about the 
enrollment and optionally returns a user ID and password to be used during subsequent signons. 

To allow a client proxy system to enroll multiple clients, Bill Presentment allows multiple <ENROLLRQ> 
requests in the same Open Financial Exchange file, each wrapped in a <ENROLLTRNRQ>. A given bill 
publisher may not need some required fields in the <ENROLLRQ>; in such a case, the client proxy system 
can include dummy data. 



15.3.2 Account Inquiry 

To receive account information from a bill publisher, the client can use the standard Open Financial 
Exchange <ACCTINFORQ> aggregate, contained in the <ACCTINFOTRNRQ> wrapper. 

The <ACCTINFORS> response returns a <PRESACCTINFO> aggregate for each of the customer's 
accounts with the billers at that bill publisher. Typically, the response will list only those accounts that have 
been activated for Bill Presentment service, not all available accounts. 

Unlike a financial institution, bill publishers generally won't have information about all the accounts of its 
supported billers. Billers that act as their own bill publishers may be able return available accounts as well 
as activated accounts. The bill publisher can use the <AVAILACCTS> element in the profile for the 
Signup message set to indicate whether the server can return available account information. 

If the server cannot return information about all available accounts, the client must ask customers for 
account information prior to requesting service activation for one or more accounts. 
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15.3.2.1 Bill Presentment Account Information <PRESACCTINFO> 



The <PRESACCTINFO> aggregate appears within the <ACCTINFORS> aggregate. 



Tag 


Description 


<PRESACCTlNFO> 


Opening tag for bill presentment account information 


<PRESACCTFROM> 


Bill presentment account identification, see section 15.3.2.2 


</PRESACCTFROM> 




<SVCSTATUS> 


Status of the Bill Presentment service for this account- AVAIL, 
PEND, ACTIVE, or REJECTED 


<REASON> 


Relevant only if REJECTED, A-255 


</PRESACCTINFO> 


Closing tag for bill presentment account information 



15.3.2.2 Account Identification <PRESACCTFROM> <PRESACCTTO> 

The <PRESACCTFROM> aggregate uniquely identifies a customer's account with a biller by the 
combination of bill publisher, biller ID, and account number. Biller IDs must be unique within a bill 
publisher. 



Tag 


Description 


<PRESACCTFROM> 




<BILLPUB> 


Official standard name of bill publisher, A-32 


<BILLERID> 


ID of this biller at this bill publisher, A-12 


<ACCTID> 


Account number, A-32 


<PRESNAMEADDRESS> 


Customer's name and address, see section 15.3.2.2.1 


</PRESNAMEADDRESS> 




<USERlD> 


Customer's user ID, A-32 


</PRESACCTFROM> 





<PRESACCTTO> follows the same structure as <PRESACCTFROM>. 
15.3.2.2.1 Customer Information <PRESNAMEADDRESS> 



Tag 


Description 


<PRESNAMEADDRESS> 


Customer name and address information 


<NAME> 


Customer's name, A-32 


<ADDR1> 


Customer's address line 1 , A-32 


<ADDR2> 


Customer's address line 2, A-32 


<ADDR3> 


Customer's address line 3, A-32 


<CITY> 


Customer's city, A-32 


<STATE> 


Customer's state, A-5 


<POSTALCODE> 


Customer's postal code, A-11 


<COUNTRY> 


Customer's country; 3-letter country code from ISO/DIS-3166, A-3 


<PHONE> 


Customer's telephone number, A-32 


</PRESNAMEADDRESS> 
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15.3.3 S rvice Activation 



Bill Presentment uses the standard service activation messages defined in Chapter 8 of the Open Financial 
Exchange specification. 

The account service request aggregate <ACCTRQ> accepts action-specific aggregates for service 
additions, changes, and deletions. To add Bill Presentment service to an account, the client sends an 
<ACCTRQ> with an <S VCADD> for the service <SVOPRESSVC. 

15.3.3.1 Service Addition <SVCADD> 

Bill Presentment defines a variant of the service addition aggregate <SVCADD>. This variant contains the 
<PRESACCTTO> aggregate and <PREAUTHTOKEN> element. 

The <PRESACCTTO> aggregate identifies the customer's name and address <PRESNAME ADDRES S>, 
as it is registered at the biller. Clients are REQUIRED to include the <PRESNAMEADDRESS> aggregate 
in the <PRESACCTTO> aggregate when they send an <ACCTRQ>. 

The <PRESACCTTO> aggregate also identifies the requester's user ID <USERID>. Clients can optionally 
include a <USERID> that is different from the one used in the <SONRQ>. This <USERID> supports 
account activation by a third party on behalf of a user. It is up to the server whether to honor such a request, 
based on access rights granted to the <SONRQ> user. More than one <SVCADD>, on behalf of multiple 
<USERID>s, can be present in a single <OFX> file. 

In some cases, the biller might provide the customer with information out-of-band to expedite service 
activation. For instance, the biller might provide a confirmation number on the customer's printed 
statement. The client can provide this additional information through the <PREAUTHTOKEN> element. 



HI 





Description 


<SVCADD> 


Opening tag for the service addition 


<PRESACCTTO> 


Account for which Bill Presentment service should be added. See 
section 15.3.2.2 


</PRESACCTTO> 




<PREAUTHTOKEN> 


A token provided out-of-band by biller to speed up activation of the 
account, A-32 


</SVCADD> 





15.3.4 Service Status Update for Groups of Customers 

The service activation requested with <SVCADD> will often not happen immediately. In this case, a 
request for account information <ACCTINFORQ> will return an <ACCTINFORS> with a 
<SVCSTATUS> value of PEND. To find out whether the account has been activated, the client can either 
send <ACCTINFORQ> once per session until it returns <SVCSTATUS>ACTIVE, or it can include an 
<ACCTSYNRQ> in each session to catch an unsolicited <ACCTRS> response to the <SVCADD> 
message. 

This section describes a method of checking for status changes on behalf of a group of customers. This 
method is designed to be used by customer service representatives and client proxy systems. 

15.3.4.1 Account Information Request <ACCTINFORQ> 

The client uses <ACCTINFORQ> to request information about accounts whose status has changed since 
the last time the request was made. This request is typically used to retrieve a list of accounts whose status 
has changed from < SVC STATU S>P END to <SVCSTATUS>ACTIVE. 



Open Financial Exchange 



321 



1 1/25/03 
Final Draft 



The <ACCTINFORQ> request must appear within a <PRESGRPACCTINFOTRNRQ> transaction 
wrapper. The transaction wrapper indicates whether the request is for a single user or a group of users. 



Tag 


Description 


<ACCTINFORQ> 
<DTACCTUP> 
</ACCTINFORQ> 


Opening tag for billing account information request 
Last <DTACCTUP> received in a response, datetime 
Closing tap for billing account information request - 



15.3.4.2 Account Information Response <ACCTINFORS> 

The <ACCTINFORS> aggregate contains zero or more <ACCTINFO> aggregates, which provide the 
updated account information. 

The <ACCTINFORS> response must appear within a <PRESGRPACCTINFOTRNRS> transaction 
wrapper 



Description 



Opening tag for billing account information response 

Date and time of last update to account information on the server, 
datetime 

Zero or more account information aggregates, see section 8.5.3. 
The <ACCTINFO> aggregate contains zero or more 
<PRESACCTINFO> aggregates. 



<ACCTINFORS> 
<DTACCTUP> 

<ACCTINFO> 

</ACCTINFO> 
</ACCTINFORS> 



Closing tag for billing account information response 



15.3.4.3 Group Account Information Transaction Request 
<PRESGRPACCTINFOTRNRQ> 



As a special transaction wrapper for <ACCTINFORQ>, <PRESGRPACCTINFOTRNRQ> specifies 
whether the client is requesting account information for a single user or a group of users. 

If the client specifies <USERID>, the client is requesting updated account information for a single user. If 
the user's account information has changed since the last time the client requested it, the server will return 
the account information in <ACCTINFORS> 

If the client specifies <GROUPID>, the client is requesting updated account information for a group of 
users. The server returns an <ACCTINFORS> response with a <PRESACCTINFO> aggregate for each 
account whose status has changed. 

The client should specify either <USERID> or <GROUPID>; if both are absent, the server uses the 
<USERID> from the signon request <SONRQ>. 



Description 



<PRESGRPACCTINFOTRNRQ> Opening tag for the transaction request 

<TRIMUID> Client-assigned globally unique ID for this transaction, trnuid 

<CLTCOOKIE> Data to be echoed in the transaction response, A-32 

_ J^JAN^ Transaction authqnzation number, A-80 

<USERID> Requests account information for the specified user, A-32 
- or - 

<GROUPID> 



Req u e sts a ceo u n t [nform a tip n f or users in the group, A-32 



Open Financial Exchange 



322 



1 1/25/03 
Final Draft 



<ACCTINFORQ> 
</ACCTINFORQ> 

</PRESGRPACCTINFOTRNRQ> Closing tag for the transaction request 

15.3.4.4 Group Account Information Transaction Response 
<PRESGRPACCTINFOTRNRS> 

As a special transaction wrapper for <ACCTINFORS>, <PRESGRPACCTINFOTRNRS> contains an 
<ACCTINFORS> aggregate with zero or more <PRESACCTINFO> aggregates. The <ACCTINFORS> 
aggregate returns one <PRESACCTINFO> aggregate for each account for which there was a change of 
status since the <DTSTART> date specified. 

The server includes information for only those user IDs for which the requester has access rights. 



El 




<PRESGRPACCTINFOTRNRS> 



Opening tag for the transaction response 

Client-assigned globally unique ID for this transaction, trnuid 



<TRNUID> 



<STATUS> 



</STATUS> 



<CLTCOOKIE> 



Data to be echoed in the transaction response, A-32 
Account information response aggregate 



<ACCTINFORS> 



</ACCTINFORS> 



</PRESGRPACCTINFOTRNRS> Closing tag for the transaction response 



15.3.4.5 Status Codes <PRESGRPACCTINFOTRNRS> 




0 Success (INFO) 

2000 General error (ERROR) 

2002 Other account/group error (ERROR) 

2006 Account/group not found (ERROR) 

2008 Account/group not authorized (ERROR) 
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15.3.5 Bill r Payment Restrictions 



In the <PAYMENTINSTRUMENTS> aggregate of <BILLERINFO> aggregate (see section 15.2.5.1), the 
biller specifies the type of payment instruments it can accept for electronic payment. Since electronic 
payment does not have to occur through the Open Financial Exchange Bill Payment message set, the 
payment instruments can include some that Open Financial Exchange doesn't support — for example, 



In some cases, a biller may have arranged for a certain party to act as its payment concentrator. This means 
that the biller expects to receive good funds and remit advice in a pre-arranged format from these 
concentrators. Such a biller will want to have customers direct their payments to the payment concentrator. 

The <PAYMENTINSTRUMENTS> aggregate supports the specification of a payment concentrator from 
which the biller wants to receive funds. However, Open Financial Exchange currently does not provide a 
way for clients to get information about payment concentrators. Knowledge of payment concentrators will 
have to be "hardwired" into client applications. For example, the client application may know that a certain 
payment concentrator, BigConcentrator, is capable of receiving DigiCash funds. A biller who has 
BigConcentrator as its payment concentrator can then accept DigiCash funds from the customer without 
having to support the DigiCash protocol and infrastructure directly. The application would direct the 
DigiCash funds to the concentrator, who would in turn transfer funds and remit advice to the biller using 
the agreed-upon method. 

NOTE: Billers in certain regulated industries are required to accept paper checks as payment — that is 
to say, a draft on the payers checking account These billers must be prepared to accept non- 
electronic payment for bills. 



15.3.5.1 Payment Instruments <PAYMENTINSTRUMENTS> 

In the <PAYMENTINSTRUMENTS> aggregate, billers list which payment instruments they accept. 



CyberCash. 




< P AYM E NTI N STRU M ENTS > 



Opening tag for payment instruments 

One or more payment instrument aggregates, see section 
15.3.5.2 



<PAYMENTINSTRUMENT> 



</PAYMENTINSTRUMENT > 



</PAYMENTINSTRUMENTS> 



Closing tag for payment instruments 
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15.3.5.2 Payment Type and Brand <PAYMENTINSTRUMENT> 



Each payment instrument is described by <TYPE> and <BRAND>. If the server does not specify 
<BRAND>, the client assumes that all brands of the given <TYPE> are acceptable. 



Tag Description 


<PAYMENTINSTRUMENT> 


Opening tag for payment instrument aggregate 


<TYPE> 


Payment type, see section 15.3.5.3 


<BRAND> 


Accepted brand for given payment type, A-32 


</P AYM ENTI NSTRU M ENT> 


Closing tag for payment instrument aggregate 



15.3.5.3 Payment Instrument Types <TYPE> 



TYPE 


Description 


Concentrator 


Party with which the biller has a business relationship and who 
will send the biller good funds and remit advice 


CheckingAccount 


Draft on a demand deposit account (US) 


CreditCard 


Payment by Auth/Settie using Credit Card networks 


ECoin 


Protocol for payment with electronic cash 



If the <BILLERINFO> does not list <PAYMENTINSTRUMENTS>, the following single 
<PAYMENTINSTRUMENT> is implied: 

< PAYMENT INSTRUMENTS 

<TYPE>CheckingAccount 
< / PAYMENT I NST RUMENT> 

15.4 Bill Delivery 

The Bill Delivery message set contains messages to obtain bills. The message set 
<PRESDLVMSGSETV1> contains the following tags: <PRESDLVMSGSRQV1> and 
<PRESDLVMSGSRSV1>. 

15.4.1 Bill Delivery Process 

Typically, the client periodically requests a list of bills from the bill publisher. The bill publisher responds 
with a list of bills, each of which contains summary data such as the due date and amount due. For each 
bill, the bill publisher might also return a URL to a Web site that contains an HTML-rendered version of 
the bill. Depending on the client's request, the server might also return structured bill detail for a given bill. 

The aggregate for a bill list request is <PRESLISTRQ>. This request must be wrapped inside 
<PRESL1STTRNRQ>. There is no synchronization wrapper for bill list requests, since clients that require a 
list of bills can send another <PRESL1STRQ>. 
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The transaction wrapper <PRESLISTTRNRQ> contains optional elements that allow bills for one or more 
customers to be accessed by customer service representatives or client proxy systems. It is up to the server 
to decide who can access bills other than their own; it is recommended that all such access be logged in an 
audit trail. 

15.4.2 Bill List Retrieval 

<PRESLISTRQ> retrieves bills from the bill publisher. The bill publisher returns a <PRESLISTRS> 
response that contains a list of one or more bills. 

15.4.2.1 Bill List Request <PRESLISTRQ> 



The client requests bills from a bill publisher by date range. To specify the date range, clients use 
<DTSTART> and <DTEND>, as described in section 3.2.7. The request doesn't specify an individual 
biller; it covers all the billers whose bills are published by the specified bill publisher. 

The bill publisher returns information sufficient to identify the biller and provide the amount due, due date, 
and remittance information so that a payment can be made to the biller. The bill publisher does not provide 
a viewable form of the bill, but returns a URL to an HTML rendering of the bill. Billing detail, such as 
individual purchases or transactions, can be included in the original response or obtained from a subsequent 
<PRESDETAILRQ>. 

The <PRESLISTRQ> must be wrapped in the <PRESLISTTRNRQ> transaction wrapper. 



<PRESLISTRQ> 
<BILLPUB> 

<DTSTART> 

<DTEND> 
<NOTIFYWILLING> 

<INCLUDEDETAIL> 
</PRESLISTRQ> 



Description 



Opening tag for bill list request 

Official standard name of bill publisher, A-32 

If present, indicates earliest date for which to include bills, 
datetime 

If present, indicates latest date for which to include bills, datetime 

Flag indicating that client is prepared to send notifications of bill 
delivery, if desired (see section 15.4.5), Boolean 

Flag indicating bill detail should be included too, Boolean 

Closing tag for bill list request 
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15.4.2.2 Bill List Response <PRESLISTRS> 

The <PRESLISTRS> response must appear within a <PRESLISTTRNRS> transaction wrapper. 

The <PRESLISTRS> response scan contain zero or more bill summaries, with optional detail. Each bill 
summary corresponds to a (usually monthly) bill. 



Tag 


Description 


<PRESLISTRS> 


Opening tag for bill list response 


<BILLPUB> 


Official standard name of bill publisher, A-32 


<USERID> 


User whose bill data is being returned, A~32 


<DTSTART> 


Start date of bills returned, datetime 


<DTEND> 


Date to present as start date for next request, datetime 


<PRESLIST> 


Opening tag for bill summary list 


</PRESLIST> 




</PRESLISTRS> 


Closing tag for bill list response 



15.4.2.2.1 Bill List <PRESLIST> 

The bill list aggregate <PRESLIST> contains a list of zero or more <PRESBILLINFO> aggregates. 



Tag 


Description 


<PRESLIST> 


Opening tag for bill list 


<PRESBILLINFO> 


Bill information aggregate (zero or more) 


</PRESBILLINFO> 




</PRESLIST> 


Closing tag for bill list 



15.4.2.2.2 Bill Information <PRESBILLINFO> 

The bill information aggregate <PRESBILLINFO> provides information about a single bill, including the 
amount due, date due, and pointers to more information. 

If the client requested bill detail in the <PRESLISTRQ>, the bill publisher provides the detail in zero or 
more <PRESDETAILRS> aggregates. If the client did not request bill detail, the server should use the 
<DETAILAVAILABLE> flag to indicate whether the client can request bill detail at a later time using the 
<PRESDETAILRQ> aggregate. 

The bill date <DTBILL> is usually a fixed number of days after the end of the bill period. It is not the date 
on which the bill publisher received the bill for publication. 
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<PRESBILLINFO> 
<FITID> 

<PRESACCTFROM> 
</PRESACCTFROM> 

<PAYEEID> 

<REMITTOKEN> 

<AMTDUE> 

<MINAMTDUE> 

<DTPMTDUE> 

<DTBILL> 

<DTOPEN> 
<DTCLOSE> 
<PREVBAL> 
<AMTPAID> 

<BAL> 

<NOT1FYDESIRED> 

<STMNTIMAGE> 
</STMNTIMAGE> 
<DETAILAVAILABLE> 
-or- 

<PRESDETAIL> 
</PRESDETAIL> 
</PRESBILLINFO> 



Description 



Opening tag for bill information 

Identifier for this bill, FITID 

Bitler account information (see section 15.3.2.2) 

Payee identifier. Specify only if the bill publisher is also provides 
Bill Payment service. See section 15.5. A-12 

Biller-defined text to include with the payment, for the hitler's 
Accounts Receivable reconciliation. See section 15.5. A-255 

Full payment amount due, amount 

Minimum payment amount due, amount 

Payment due date, datetime 

Bill date, datetime 

Opening statement date, datetime 

Closing statement date, datetime 

Balance of the account as of the previous period, amount 

Net payments received and credited to the account since the last 
period, amount 

Balance of the account prior to the bill being sent, amount 

Indicator that a delivery notification (see section 15.4.5) is 
desired, Boolean 

Statement image aggregate, see section 15.4.2.2.3 

Indicator that structured detail is available, Boolean 

Zero or more bill details, when requested, see section 15.4.3.2 

Closing tag for bill information 



If <PREVBAL>, <AMTPAID>, and <BAL> are all present, then <BAL> and <AMTPAID> must add up 
to <PREVBAL>. 

15.4.2.2.3 Statement Image <STMNTIMAGE> 

The <STMNTIMAGE> aggregate provides one or more URLs that point to a fully rendered image of the 
bill, in HTML. 

<IMAGEURL> accesses the complete bill image. This URL may contain navigation to other sites, or to 
other pages of bill images at the same site. 

To support off-line viewing of the bill, the server may provide one or more additional URLs. Each 
<PREFECTCHURL> points to a local Web page. 
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Each URL associated with <IMAGEURL> and <PREFETCHURL> must include an authentication token 
at the end (for example, lauthtoken^randomString). These embedded tokens guarantee that only the 
customer can access the Web page. Accessing the statement image requires SSL. The bill publisher might 
include an expiration date for the authentication token, and hence for the URLs. The expiration date could 
be quite short (for example, 1 hour) or quite long (for example, 1 month). After the expiration date, the 
client can obtain a new authentication token only by sending a new <PRESLISTRQ> request. 



Tag Description 


<STM NTI MAG E> 


Opening tag for statement image 


<IMAGEURL> 


URL address for retrieving an image of the complete bill encoded 
as HTML. This can be cached by the client for later display, or it 
can be viewed live directly from the Web. url 


<PREFETCHURL> 


Advice in support of off-line viewing. Zero or more, url 


<DTEXPIRE > 


Date after which embedded authentication token expires, 
datetime 


</STMNTIMAGE> 


Closing tag for statement image 



15.4.2.3 Bill List Transaction Request <PRESLISTTRNRQ> 

As the transaction wrapper for <PRESLISTRQ>, this aggregate specifies whether the client is requesting 
bills for a single user or a group of users. The optional <USERID> and <GROUPID> elements support the 
following scenarios: 

• A customer requests his or her own bills from the bill publisher: In this case, the client can 
optionally specify the customer's <USERID> in the <PRESLISTTRNRQ>. If the client does not 
specify <USERID>, the bill publisher uses the <USERID> in the signon request <SONRQ>. 

• A customer service representative requests a bill on behalf of a user: The client sends the 
representative's <USERID> in the signon request <SONRQ>. To specify the user for which the 
representative is retrieving bills, the client sends the customer's <USERID> in the 
<PRESLISTTRNRQ>. The bill publisher must ultimately decide whether the customer service 
representative can access the requested bills. In its response, the bill publisher includes only those bills 
for which the requester has access privileges. 

• A client proxy system fetches bills on behalf of a group of users: Instead of sending a <USERID>, 
the client sends the <GROUPID> that identifies the group of users. Within the <PRESLISTTRNRS>, 
the bill publisher returns a <PRESLISTRS> for each user in the named group. Again, the bill publisher 
decides whether access should be granted. Bill publishers that support usage of the <GROUPID> must 
maintain knowledge of which users are in which named group. The Open Financial Exchange 
specification does not provide a way to track membership in a named group. Any such management 
must happen out-of-band. 



Open Financial Exchange 



329 



11/25/03 
Final Draft 



BR 



Tag Description 


<PRESLISTTRKIRG> 


Opening tag for bill list transaction request 


<TRNUID> 


Client-assigned globally unique ID for this transaction, trnuid 


<CLTCOOKIE> 


Data to be echoed in the transaction response, A-32 


<TAN> 


Transaction authorization number, A-80 


<USERID> 


If present, the bill request is on behalf of this particular user, 
A-32 


- or - 




<GROUPID> 


If present, the bill request is on behalf of all users in the named 
group. If both <USERID> and <GROUPID> are absent, the 
<USERID> in the <SONRQ> is implied. A-32 


<PRESUSTRQ> 


Bill List Request Aggregate 


</PRESLISTRQ> 




</PRESLISTTRNRQ> 


Closing tag for bill list transaction request 



15.4.2.4 Bill List Transaction Response <PRESLISTTRNRS> 

The transaction response returns zero or more bills <PRESLISTRS>. 



Tag 


Description 


<PRESLISTTRNRS> 


Opening tag for bill list transaction response 


<TRNUID> 


Client-assigned globally unique ID for this transaction trnuid 


<STATUS> 


Status aggregate 


</STATUS> 




<CLTCOOKIE> 


Client provided data. REQUIRED if provided in request A-32 


<PRESLISTRS> 


Bill list response aggregate, zero or more 


</PRESLISTRS> 




</PRESLISTTRNRS> 


Closing tag for bill list transaction response 



15.4.2.5 Status Codes <PRESLISTTRNRS> 



Code 


Meanina 


0 


Success (INFO) 


2000 


General error (ERROR) 


2002 


General account error (ERROR) 


2003 


Account/Group not found (ERROR) 


2004 


Account/Group closed (ERROR) 


2005 


Account/Group not authorized (ERROR) 
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15.4.3 Bill D tail Retrieval 

If statement detail is available for a bill, the client can retrieve the detail using a bill detail request 
(<PRESDETAILRQ). One example of statement detail is the individual telephone calls from a telephone 
bill. 

15.4.3.1 Bill Detail Request <PRESDETAILRQ> 

The <PRESDETAILRQ> request must appear within a <PRESDETAILTRNRQ> transaction wrapper. 



n 



Tag Description 


<PRESDETAILRQ> 


Opening tag for bill detail request 


<FITID> 


Statement identifier from <BILLINFO>, fitid 


<TABLETYPE> 


If present, filters response to just tables of this type. See table 
15.4.3.2.3 


</PRESDETAJLRQ> 


Closing tag for bill detail request 



15.4.3.2 Bill Detail Response <PRESDETAILRS> 

The <PRESDETAILRS> request must appear within a <PRESDETAILTRNRS> transaction wrapper. 
The bill detail response contains zero or more <TABLE> aggregates. 



Tag 


Description 


<PRESDETAILRS> 


Opening tag for bill detail response 


<PRESDETAIL> 


Opening tag for bill detail aggregate 


<FITID> 


Statement identifier from <BILLINFO>, fitid 


<PRESACCTFROM> 


Identifies biller account. Must be included if in response to an 
<PRESDETAILRQ>, is redundant inside <PRESBILLINFO> 


</PRESACCTFROM> 




<TABLE> 


Zero or more bill detail table aggregates. See section 15.4.3.2.1. 


</TABLE> 




</PRESDETAIL> 


Closing tag for bill detail aggregate 


</PRESDETAILRS> 


Closing tag for bill detail response 



15.4.3.2.1 Bill Detail Table <TABLE> 

The bill detail table allows billers to send tabular data to the customer in a flexible way. The table might 
contain phone calls from a telephone bill, or electrical meter readings for a utility bill. 

A table consists of one or more rows, each having one or more columns. Within a table, all rows must have 
identical structures. The <TABLETYPE> determines the "shape" or schema of the table. The 
<TABLENAME> gives a name to this table, and should be unique within an <PRESDETAILRS>. 
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Tag Description 



<TABLE> 
<TABLENAME> 
<TABLETYPE> 

<ROW> 
</ROW> 
</TABLE> 



Opening tag for bill detail table 

Name of bill detail table, A~32 

Type of bill detail table, see section 15.4.3.2.3 

Zero or more bill detail row aggregates, see section 15.4.3,2.2 

Closing tag for bill detail table 



15.4.3.2.2 Bill Detail Row <ROW> 



A <TABLE> contains zero or more bill detail rows <ROW>. 

A <ROW> contains zero or more columns <C>, whose meanings are specific to the type of table 
<TABLETYPE> in which they occur. For the purpose of the DTD parser, all columns <C> are consider to 
be Format: A-255. 



Bill publishers can return blank columns. Additionally, bill publishers can omit blank columns at the end of 
a<ROW>, tag and all. 



Tag 


Description 


<ROW> 


Opening tag for bill detail row 


<C> 


Zero or more column data elements, ,4-255 


</ROW> 


Closing tag for bill detail row 



15.4.3.2.3 Table Types <TABLETYPE> 



Open Financial Exchange defines some common table types. Individual billers can define their own table 
types, and hence their own table structures, but must honor the custom tag naming convention outlined in 
section 2.7 of the Open Financial Exchange specification. 



Value Description 



TransactionList Table defined for "payment register"-style line items 

CallLog Table defined for record of telephone calls 

XXX. Usage Table defined by biller, not by Open Financial Exchange 

1 5.4.3.2.3. 1 TransactionList Table Type 



<TABLE> aggregates marked with <T ABLET YPE>TransactionList have rows of 14 columns. The first 
column contains a unique identifier (like an FITID), and must be present. Other columns may not always 
apply and can be left blank. 

The TransactionList table type is a subset of the <STMTRN> aggregate in section 1 1 .4.2.3.1. 
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Column 


Name 


Description 


1 


Fitld 


Unique identifier token from server, fitid 


2 


TmTunp 
1 1 1 1 1 y|jc 


Transaction type (see section 11.4.2.3.1.1) 


3 




uaie iiem was posted, uatevme 


4 


Dtl l<;pr 


Date user initiated transaction, if known, datetime 




TrnAmount 


Amount of transaction, amount 


g 


Pnrror»tPitl/H 
\-rOrrtJClrlllu 


If present, unique identifier of previously sent transaction that is 
corrected by this record, fitid 


7 


CorrectAction 


Replace or delete. Specify only if column 6 is present. 


8 


CheckNum 


Check or other reference number, A-12 


9 


RefNum 


Other reference number, A-12 


10 


SIC 


Standard Industrial Code, N-6 


11 


Name 


Name of payee or description of transaction, A~32 


12 


Memo 


Extra Information, A-255 


13 


OrigCurSym 


Original Currency Identifier (ISO 42173 3-letter), A-3 


14 


CurRate 


Currency rate, ratio of currency to original currency, rate 



1 5.4.3.2.3.2 CallLog Table Type 

<TABLE> aggregates marked with <T ABLET YPE>CallLog have rows of 10 columns. 



Column 


Name 


Description 


1 


TNCalledFrom 


Telephone number called from, A-32 


2 


CityStateFrom 


City, state (or place, region) called from, A-16 


3 


TNCalled 


Telephone number called, A-32 


4 


CityState 


City, state (or place, region) called, A-16 


5 


Originated 


Date/time call started, datetime 


6 


Type 


Type of call, A-8 


7 


Rate 


Rate (for example, Night, Day, Eve, Wknd), A-5 


8 


Duration 


Duration of call in tenths of seconds, N-6 


9 


Cost 


Cost of call, amount 


10 


TNCharqedTo 


Telephone number charged to, A-32 



15.4.3.3 Status Codes <PRESDETAILTRNRS> 



Code Meanim 



0 Success (INFO) 

2000 General error (ERROR) 

2003 FITID not found (ERROR) 

2005 Table type not found (ERROR) 
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15.4.4 Tabl Structure Definition 



Clients can obtain the definition of a table structure by sending a table structure request 
<TBLSTRUCTRQ>. 

Clients need only request the structure of tables it does not already know about. For instance, the client 
might request the structure of a biller-specific table that starts with the x- prefix. Knowing the structure of a 
table allows the client to display the data more clearly or store the data in a more compact form, such as a 
database table. 

15.4.4.1 Table Structure Request <TBLSTRUCTRQ> 

To identify the table, the client includes the type of table <TABLETYPE> and unique identifier <FITID> 
for the table. Although <TABLETYPE> uniquely identifies the table, Open Financial Exchange requires 
the <FITID> as well to allow various server implementations. 

The <TBLSTRUCTRQ> request must appear within a <TBLSTRUCTTRNRQ> transaction wrapper. 



Tag 


Description 


<TBLSTRUCTRQ> 


Opening tag for the table structure request 


<FITID> 


Statement Identifier, fitid 


<TABLETYPE> 


Table type for which the structure is requested 


</TBLSTRUCTRQ> 


Closing tag for the table structure request 



15.4.4.2 Table Structure Response <TBLSTRUCTRS> 

The <TBLSTRUCTRS> response must appear within a <TBLSTRUCTTRNRS> transaction wrapper. 

The table structure response contains one or more column type definitions, which correspond positionally 
with the <C> aggregates in a <ROW> in a <TABLE> of the corresponding <T ABLET YPE>. 



mm 



Tag Description 


<TBLSTRUCTRS> 


Opening tag for table structure response 


<FITID> 


Table identifier, fitid 


<TABLETYPE> 


Table type 


<COLDEF> 


Zero or more column definition aggregates (see section 
15.4.4.2.1) 


</COLDEF> 




</TBLSTRUCTRS> 


Closing tag for table structure response 
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15.4.4.2.1 Column Definition <COLDEF> 



A column definition <COLDEF> associates a name and a data type with a column. 



Tag Description 


<COLDEF> 


Opening tag for column definition 


<COLNAME> 


Column name, A-32 


<COLTYPE> 


Column type, in A-255/D/N-6 notation, A-8 


</COLDEF> 


Closing tag for column definition 



15.4.4.3 Status Codes <TBLSTRUCTRS> 




0 Success (INFO) 

2000 General error (ERROR) 

2003 FITID not found (ERROR) 

2005 Table type not found (ERROR) 



15.4.5 Delivery Notification 

The bill publisher can request delivery notification through the <NOTIFYDESIRED> flag in the 
<PRESBILLINFO> aggregate (see section 15.4.2.2.2). The bill publisher will expect to receive the delivery 
notification only if the <PRESLISTRQ> had the <NOTIFYWILLING> flag set. 

The delivery notification request tells the bill publisher that the client has presented the specified bills to the 
customer. This is a stronger statement than acknowledging that the bills have been received by the client, 
specifically when the client software implements the pre-fetching or (push) model. 

However, Open Financial Exchange does not define the meaning of "presenting to the customer." In 
particular, receipt of a delivery notification by the bill publisher has no legal significance. Open Financial 
Exchange also does not define the maximum elapsed time between the presentation of the bill and the 
delivery notification. 

15.4.5.1 Delivery Notification Request <PRESNOTIFYRQ> 

The <PRESNOTIFYRQ> request must appear within a <PRESNOTIFYTRNRQ> transaction wrapper. 



Tag 


Description 


<PRESNOTIFYRQ> 


Opening tag for delivery notification request 


<PRESDELIVERYiD> 


Zero or more bill delivery ID aggregates (see section 15.4.5.1 .1) 


</PRESDELIVERYID> 




</PRESNOTIFYRQ> 


Closing tag for delivery notification Request 
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15.4.5.1 .1 Bill Delivery Identification <PRESDELIVERYID> 

This aggregate identifies a bill delivery instance and suggests when the bill was "seen." 

<DTSEEN> is the date and time at which the client displayed the bill to the customer. There is no legal 
significance to this bill delivery identification. 



Tag Description 


<PRESDELIVERYID> 


Opening tag for the bill delivery identification 


<PRESACCTFROM> 


Biller account information 


</PRESACCTFROM> 




<FITID> 


Identifies the bill from the given biller, fitid 


<DTSEEN> 


Date and time at which the bill was made available to the 
requester's client, datetime 


</PRESDELIVERYID> 


Closing tag for the bill delivery identification 



15.4.5.2 Delivery Notification Response <PRESNOTIFYRS> 

The <PRESNOTIFYRS> response must appear within a <PRESNOTIFYTRNRS> transaction wrapper. 

The delivery notification response lets the client know that the delivery notification request was received by 
the bill publisher. 



El 



Tag Description 


<PRESNOTIFYRS> 


Opening tag for Delivery Notification Response 


<PRESDELIVERYID> 


Zero or more bill delivery ID aggregates 


</PRESDELIVERYID> 




</PRESNOTIFYRS> 


Closing tag for Delivery Notification Response 



15.4.5.3 Status Codes <PRESNOTIFYTRNRS> 




0 Success (INFO) 

2000 General error (ERROR) 

2005 FITID not found (ERROR) 
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15.5 Bill Payment 



To pay a bill received through a <PRESLISTRQ> request, the client can use the Bill Payment message set 
defined in Chapter 12. To construct the payment information <PMTINFO> (see section 12.5.2), the client 
can use the bill information from <PRESBILLINFO>. 

15.5.1 Remittance Information 

The client should include the <REMITTOKEN> from the <PRESBILLINFO> aggregate as the 
<BILLREFINFO> in the <PMTINFO> aggregate. This token allows the biller to link the payment with the 
bill. 

15.5.2 Payee Identification 

Client software can produce <PAYEEID> or <PAYEE> in one of two ways. 

If the Bill Presentment and Bill Payment are provided by the same company, the client can use the 
<PAYEEID> included in the <PRESBILLINFO> aggregate. 

If the Bill Payment provider is a different company, the client must use information from the 
<PRESACCTINFO> to construct the <PAYEE> information. The client can then retrieve the <PAYEEID> 
from the payment response. 



15.6 Bill Presentment E-Mail 

Open Financial Exchange currently defines a Bill Presentment e-mail message that clients can send to bill 
publishers. With this message, a customer can send a message to a bill publisher regarding one of his or her 
accounts. 

The server acknowledges receipt of the message. The bill publisher then prepares a response that the client 
picks up when it synchronizes with the server. E-mail is subject to synchronization, using 
<PRESMAILSYNCRQ> and <PRESMAILSYNCRS>. 



Client Sends 


Server Responds 


Addressed message 




PRES account information 






Acknowledgment 


Synchronization request 






Response to customer 
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15.6.1 BillPr sentment Mail Request <PRESMAILRQ> 

The client must identify the account to which account the customer query is related. 

The <PRESMAILRQ> request must appear with a <PRESMAILTRNRQ> transaction wrapper. 



Tag Description 


<PRESMAILRQ> 


PRES-e-mail-request aggregate 


<PRESACCTFROM> 


Account-from aggregate 


</PRESACCTFROM> 




<MAIL> 


To, from, message information, see section 9.2.2 


</MAIL> 




</PRESMAILRQ> 





15.6.2 Bill Presentment Mail Response <PRESMAILRS> 

The <PRESMAILRQ> request must appear with a <PRESMAILTRNRQ> transaction wrapper. 



Tag Description 


<PRESMAILRS> 


PRES-e-mait-response aggregate 


<PRESACCTFROM> 


Account-from aggregate 


</PRESACCTFROM> 




<MAIL> 


To, from, message information, see section 9.2.2 


</MAIL> 




</PRESMAJLRS> 





15.6.3 Status Codes <PRESMAILTRNRS> 



Code 


Meanino 


0 


Success (INFO) 


2000 


General error (ERROR) 


2002 


General account error (ERROR) 


2003 


Account not found (ERROR) 


2004 


Account closed (ERROR) 


2005 


Account not authorized (ERROR) 


2019 


Duplicate transaction (ERROR) 


16500 


HTML not allowed (ERROR) 


16501 


Unknown mail To: (ERROR) 
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15.7 Message Sets and Profile 



Open Financial Exchange separates the messages that the client and server send into groups called message 
sets. In its profile response <PROFRS>, each bill publisher or other server provider defines the message 
sets that it supports and any options available for those message sets. 

This section defines the message sets supported by Bill Presentment. It then describes the corresponding 
message set profile aggregates that can be provided in the profile response <PROFRS>. The message set 
profile aggregates for the <PROFRS> allow a bill publisher or other server provider to customize its use of 
Open Financial Exchange. For example, a server might support the Bill Delivery message set 
(<PRESDLVMSGSET>), but not the Group Account Information message set 
(<PRESACCTINFOMSGSETVl>). 

For general information about profiles, see Chapter 7 of the Open Financial Exchange specification. 

15.7.1 Message Sets and Messages 

Bill Presentment defines the following message sets: 

• Biller Directory message set (<PRESDIRMSGSET>), which includes messages for finding billers 
and bill publishers 

• Bill Delivery message set (<PRESDLVMSGSET>), which includes messages for delivering bills 
and bill detail to customers 

• Group Account Information message set (<PRESACCTINFOMSGSET>), which includes 
messages for getting account information for a group of users 

15-7.1.1 Biller Directory Message Set and Messages 

15.7.1.1.1 Biller Directory Request Messages 



Message Set 


Messaqe 


<PRESDIRMSGSET> 




<PRESD!RMSGSETV1> 




<PRESDIRMSGSRQV1> 


FINDBILLERTRNRQ 




FINDBILLERRQ 


</PRESDIRMSGSRQV1> 




</PRESDIRMSGSETV1> 




</PRESDIRMSGSET> 
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15.7.1.1.2 Biller Directory Response Messages 



Message Set 


Message 


<PRESDIRMSGSET> 




<PRESDIRMSGSETV1 > 




<PRESDI RMSGSRS V1 > 


FINDBILLERTRNRS 




FINDBILLERRS 


</PRESDIRMSGSRSV1> 




</PRESDIRMSGSETV1> 




</PRESDIRMSGSET> 





15.7.1.2 Bill Delivery Message Set and Messages 

15.7.1.2.1 Bill Delivery Request Messages 



Message Set 


Message 


<PRESDLVMSGSET> 




<PRESDLVMSGSETV1> 




<PRESDLVMSGSRQV1> 


PRESLISTTRNRQ 




PRESLISTRQ 




PRESDETAILRQ 




PRESTABLESTRUCTRQ 




PRESNOTIFYRQ 


</PRESDLVMSGSRQV1> 




</PRESDLVMSGSETV1> 




</PRESDLVMSGSET> 





15.7.1.2.2 Bill Delivery Response Messages 



| Message Set 


Message 


<PRESDLVMSGSET> 




<PRESDLVMSGSETV1> 




<PRESDLVMSGSRSV1> 


PRESLISTTRNRS 




PRESLISTRS 




PRESDETAtLRS 




PRESTABLESTRUCTRS 




PRESNOTIFYRS 


</PRESDLVMSGSRSV1> 




</PRESDLVMSGSETV1> 




</PRESDLVMSGSET> 
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15.7.1.3 Group Account Information Message Set and Messages 

15.7.1.3.1 Group Account Information Request Messages 



Message Set 


Messaae 


<PRESACCTINFOMSGSET> 




<PRESACCTINFOMSGSETV1> 




<PRESACCTINFOMSGSRQV1 > 


PRESGRPACCTINFOTRNRQ 
PRESACCTINFORQ 


</PRESACCTINFOMSGSRQV1> 




</PRESACCTINFOMSGSETV1> 




</PRESACCTINFOMSGSET> 





15.7.1 .3.2 Group Account Information Response Messages 



Message Set 


Messaae 


<PRESACCTINFOMSGSET> 




<PRESACCTINFOMSGSETV1 > 




<PRESACCTINFOMSGSRSV1 > 


PRE SGRPACCTI NFOTRNRS 




PRESACCTINFORS 


</PRESACCTINFOMSGSRSV1> 




<PRESACCTINFOMSGSETV1> 




</PRESACCTINFOMSGSET> 





15,7.2 Biller Directory Message Set Profile 

This section defines the profile aggregate for the Biller Directory message set. This profile aggregate 
should be included in the <PROFRS> response for those servers that support the Biller Directory message 
set. 



| Message Set 


Messaae 


<PRESDIRMSGSET> 


Opening tag for the Biller Directory message set profile 


<PRESDIRMSGSETV1> 


Version 1 of Biller Directory message set 


<MSGSETCORE> 


Common message-set core 


</MSGSETCORE> 




<PRESDIRPROF> 


Directory profile (if supported) 


<PROCDAYSOFF> 


Days of week that no processing occurs: MONDAY, 
TUESDAY, WEDNESDAY, THURSDAY, FRIDAY, 
SATURDAY, or SUNDAY. 0 or more <PROCDAYSOFF> 
can be sent. 


<CANSUPPORT1MAGES> 


Supports delivery of images as multi-part MIME, Boolean 


<PROCENDTM> 


Time of day that day's processing ends, time 


</PRESDIRPROF> 




</PRESDIRMSGSETV1> 




</PRESDIRMSGSET> 


Closing tag for the Biller Directory message set profile 
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15.7.3 Bill Deliv ry M ssag S t Profil 



This section defines the profile aggregate for the Bill Delivery message set. This profile aggregate should 
be included in the <PROFRS> response for those servers that support the Bill Delivery message set. 



Tag 


Description 


<PRESDLVMSGSET> 


Opening tag for the Bill Delivery message set profile 


<PRESDLVMSGSETV1> 


Version 1 of Bill Delivery message set 


<MSGSETCORE> 


Common message-set core 


</MSGSETCORE> 




<PRESDLVPROF> 


Bill Delivery profile (if supported) 


<PROCDAYSOFF> 


Days of week that no processing occurs: MONDAY, 
TUESDAY, WEDNESDAY, THURSDAY, FRIDAY, 
SATURDAY, or SUNDAY. 0 or more <PROCDAYSOFF> can 
be sent. 


<CANSUPPORTIMAGES> 


Supports delivery of images as multi-part MIME, Boolean 


<PROCENDTM> 


Time of day that day's processing ends, time 


</PRESDLVPROF> 




<EMAILPROF> 


E-mail profile 


<CANEMAIL> 


Supports generalized e-mail, Boolean 


<CANNOTIFY> 


Supports notification (of any kind), Boolean 


</EMAILPROF> 




</PRESDLVMSGSETV1> 




</PRESDLVMSGSET> 


Closing tag for the Bill Delivery message set profile 
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15.7.4 Group Account Information Messag Set Profile 



This section defines the profile aggregate for the Group Account Information message set. This profile 
aggregate should be included in the <PROFRS> response for those servers that support the Group Account 
Information message set. 



Tag 


Description 


<PRESACCTINFOMSGSET> 


Opening tag for Group Account Information message set 
profile 


<PRESACCTINFOMSGSETV1 > 


Version 1 of Group Account Information message set 


<MSGSETCORE> 


Common message-set core 


</MSGSETCORE> 




<PRESACCTINFOPROF> 


Group Account Information profile (if supported) 


<PROCDAYSOFF> 


Days of week that no processing occurs: MONDAY, 
TUESDAY, WEDNESDAY, THURSDAY, FRIDAY, 
SATURDAY, or SUNDAY. 0 or more <PROCDAYSOFF> can 
be sent. 


<PROCENDTM> 


Time of day that day's processing ends, time 


</PRESACCTINFOPROF> 




</PRESDLVMSGSETV1> 




</PRESDLVMSGSET> 


Closing tag for Group Account Information message set 
profile 



15.8 Bill Presentment Examples 

15.8.1 Find Biller Examples 
15.8.1.1 Get All Billers 

The client sends a <FINDBILLERRQ> request to retrieve all available billers: 

<FINDBILLERRQ> <! — Beginning of find biller request — > 

<INCIMAGES>N <! — LOGO Images are not requested — > 

</FINDBILLERRQ> <! — End of request — > 

To keep the size of the example reasonable, we will assume that there are only four billers. Here is the 
server reply. 



<FINDBILLERRS> 

<DTUPDATE>1 99 604 15092000 

<BILLERINFO> 

<BILLPUB>Wepubbills 
<BILLERID>12 34 567 8 9 
<NAME>RealBig Credit Co. 
<ADDR1>1324 Whatever St. 
<CITY>MajorMetro 
<STATE>OH 

<POSTALCODE>12 34 5-1234 

<COUNTRY>USA 

<SIC>23 

<PHONE>614-2 35-2323 
< PAYMENT I NSTRUMENTS> 
< PAYMENT INSTRUMENTS 



<! --Beginning of response--> 

<! — Date last update 04/15/97 9:20am — > 

<!— Name of Bill Publisher — > 

<! — Biller ID at Wepubbills — > 

< ! --Name of biller — > 

<! — Street address of biller — > 

<! — City of the Biller — > 

<! — State of the biller — > 

<! --Postal code of biller — > 

<! — Standard Industry Code of biller — > 

<! --Biller' s phone number— > 

<! — Type of payment accepted~> 
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<TYPE>CheckingAccount 
</PAYMENTINSTRUMENT> 
< PAYMENT INS TRUMENT> 
<TYPE>Concentrator 
<BRAND>CityBank 
</ PAYMENT INSTRUMENTS 
</PAYMENTINSTRUMENTS> 
<ACCT FORMAT > ( [0-9] \{3\}-> \{3\} 

<ACCTEDITMASK>" - - - 



<! — 
< ! — 



< ! - 



<LOGO>http : / /www . realbig . com/logo . gif 

<!- 

</BILLERINFO> 
<BILLERINFO> 



-Regular expression describing — > 
-biller' s account number— > 

-Edit mask for account number— > 

-URL to logo of biller — > 



Name of Bill Publisher — > 
Biller ID at Wepubbills — > 
Name of biller — > 
Street address of biller — > 
City of the biller — > 
State of the biller — > 
Postal code of biller — > 



-Standard Industry Code of biller- 
-Biller' s phone number— > 
-Type of payment accepted — > 
<PAYMENTINSTRUMENT> 

<TYPE>CheckingAccount 
</PAYMENTINSTRUMENT> 
</PAYMENTINSTRUMENTS> 

<ACCT FORMAT > ( [ 1-9] \ { 2\ > - ) \ { 2\ } [ 0-9] \ { 3\ > 

<! --Regular expression describing — > 
<! — biller' s account number — > 
<ACCTEDITMASK>" - < ! — Edit mask for account number--> 

<LOGO>http : / /www . webup . com/aphone . gif 

<! — URL to logo of biller — > 



<BILLPUB>Wepubbills 


<!--: 


<BILLERID>222 334 4 65 


< ! — 


<NAME>Aphone Company 


<! — i 


<ADDR1>1324 Where Blvd 


<! — , 


<CITY>Sometown 


<! — < 


<STATE>CA 


<! — 


<POSTALCODE>10992-1234 


<! — 


<COUNTRY>USA 




<SIC>39 


< ! — ; 


<PHONE>345-345-348 9 


<! — ] 


< PAYMENT INS TRUMENTS> 


<! — ' 



</BILLERINFO> 

<BILLERINFO> 

<BILLPUB>Wepubbills 
<BILLERID>987 651234 54 
<NAME>Goodol Mortgage 
<ADDR1>8273 Magnolia St. 
<CITY>Atlanta 
<STATE>GA 

<POSTALCODE>34 342-678 9 

<COUNTRY>USA 

<SIC>03 

<PHONE>8 64-2 34-67 45 
< PAYMENT INSTRUMENTS> 

< PAYMENT I NSTRUMENT> 

<TYPE>CheckingAccount 

</ PAYMENT I NSTRUMENT> 
</ PAYMENT I NSTRUMENTS> 
<ACCTFORMAT> [0-1] \{12\} 



<! — Name of Bill Publisher — > 

<! — Biller ID at Wepubbills — > 

< ! --Name of biller--> 

<! — Street address of biller — > 

<! — City of the Biller — > 

<! — State of the biller — > 

<! — Postal code of biller — > 

<! — Standard Industry Code of biller--> 

<! --Biller' s phone number— > 

<! — Type of payment accepted — > 



<HELPMESSAGE>Enter the first 13 digits 

< ! — 

<RESTRICT> GA residents only. < ! -- 

<LOGO>http : / /www . wepub . com/mort . gif 

<!- 

</BILLERINFO> 
<BILLERINFO> 

<BILLPUB>Wepubbills < i - 



<! — Regular expression describing — > 
<! --biller' s account number— > 
of your account number 
to help user key account number— > 
Indicate restricted availibility — > 



-URL to logo of biller — > 



Name of Bill Publisher — > 
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<BILLERID>32 8 1281 6734 <i— 
<NAME>Sam's Widgets <!-- 
<ADDRl>Apt B3 <!-- 
<ADDR2>1267 Tank Rd 

<CITY>Columbus <! — 

<STATE>OH <!-- 
<POSTALCODE>7 772 3-8 98 9 <!— 
<COUNTRY>USA 

<SIC>12 <!-- 
<PH0NE>6 14- 657-8 934 <!-- 
<PAYMENTINSTRUMENTS> <!-- 
< PAYMENT I NSTRUMENT> 

<TYPE>CheckingAccount 
</ PAYMENT I NSTRUMENT> 
< PAYMENT I NSTRUMENT> 
<TYPE>Concentrator 
<BRAND>BigConcentrator 
< / PAYMENT INSTRUMENT > 
</ PAYMENT INST RUMENTS> 

<ACCTEDITMASK>" - - " <!-- 
<LOGO>http : / /www . relbig . com/logo . gif 

<!-- 

<VALIDATE>http : //www. wepub. com/sam. cgi 

<! — 

</BILLERINFO> 
</FINDBILLERRS> 



-Biller ID at Wepubbills — > 

-Name of biller--> 

-Street address of biller — > 

-City of Biller — > 
-State of the biller — > 
-Postal code of biller — > 

-Standard Industry Code of biller--> 
-Biller' s phone number--> 
-Type of payment accepted— > 



•Edit mask for account number— > 

■URL to logo of biller — > 

-URL used to validate acct number--> 



15.8.1.2 Find Selected Billers 



In this example, the client requests only those billers that are located in Ohio: 

<FINDBILLERRQ> 

<STATE>OH 

<INCIMAGES>N 
</FINDBILLERRQ> 

In the same circumstances as before, the response would be: 

<FINDBILLERRS> 

<DTUPDATE>199604 15092000 
<BILLERINFO> 

<BILLPUB>Wepubbills 

<BILLERID>1234 567 8 9 

<NAME>RealBig Credit Co. 

<ADDR1>1324 Whatever St. 

<CITY>MajorMetro 

<STATE>OH 

<POSTALCODE>1234 5-1234 
<COUNTRY>USA 
<SIC>23 

<PHONE> 614-2 35-232 3 
< PAYMENT INSTRUMENT S> 
<PAYMENT INSTRUMENT > 

<TYPE>CheckingAccount 
</PAYMENTINSTRUMENT> 
<PAYMENT INSTRUMENT > 
<TYPE>Concentrator 
<BRAND>CityBank 
</PAYMENTINSTRUMENT> 
</PAYMENTINSTRUMENTS> 
<ACCT FORMAT > { [0-1] \{3\}-) \{3\} <! —Regular expression describing— > 

<! --biller' s account number— > 



<! — Date last update 04/15/97 9:20am — > 

<! — Name of Bill Publisher — > 
<! — Biller ID at Wepubbills — > 
< ! — Name of biller— > 
<! --Street address of biller — > 
<! — City of the Biller — > 
<! — State of the biller — > 
<! — Postal code of biller — > 

<! — Standard Industry Code of biller — > 
<! — Biller' s phone number — > 
<!--Type of payment accepted--> 
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<ACCTEDITMASK> 



<! — Edit mask for account number — > 



<LOGO>http : //www . relbig . com/logo . gif 



</BILLERINFO> 
</FINDBILLERRS> 



<! — URL to logo of biller — > 



15.8.2 Enrollment Examples 



In this example, the client wants to enroll with a bill publisher. 

15.8.2.1 Enrollment Request Example 



<OFX> 



<SIGN0NMSGSRQV1> 



<!--Signon Request--> 



<SONRQ> 

<DTCLIENT>199703070222 4 3 

<USERID>D 

<USERPASS>D 



<! — Timestamp, 3/07/97 
<! --Dummy userid — > 
<! — Dummy password — > 



2:22:43am — > 



<LANGUAGE>ENG 
<APPID>OFXAPP 
<APPVER>0201 
</SONRQ> 
</SIGNONMSGSRQVl> 

<SIGNUPMSGSRQV1> <! —Enrollment Request— > 

<ENROLLTRNRQ> 

<TRNUID>10001 
<ENROLLRQ> 

<FIRSTNAME>Cindy 
<MIDDLENAME>P 
<LASTNAME>Williams 
<ADDR1>123 Oak St 
<CITY>San Jose 
<STATE>CA 
<POSTALCODE>94 111 
<COUNTRY>USA 
<DAYPHONE>4 15-55 5-0123 
<EVEPHONE>4 08-555-2323 
<EMAIL>cindy@aol . com 
<USERID>cindyid 
<TAXID> 11 1-33-5555 
<SECURITYNAME>wynona 
<DATEBIRTH>196504 02 
</ENROLLRQ> 
</ENROLLTRNRQ> 
</SIGNUPMSGSRQVl> 
</0FX> 
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15.8.2.2 Enrollment Response Example 



For this example, the server responds with immediate acceptance. In practice, many servers would send an 
enrollment status code of 13000 and send the user ID and password in a welcome letter. 



<OFX> 

<SIGNONMSGSRSVl> 
<SONRS> 

<STATUS> 
<CODE>0 

<SEVERITY>INFO 
</STATUS> 

<DTSERVER>1 9970307 08 14 37 
<LANGUAGE>ENG 
<DTPROFUP>l 9970 301 07 0000 
<DTACCTUP>1 9970 301 07 0000 
</SONRS> 
</SIGNONMSGSRSVl> 
<SIGNUPMSGSRSV1> 
<ENROLLTRNRS> 

<TRNUID>10001 
<STATUS> 
<CODE>0 

<SEVERITY>INFO 
</STATUS> 
<ENROLLRS> 

<TEMPPASS>y 12345 
<USERID>cindyid 
<DTEXPIRE>1 9970407 
</ENROLLRS> 
</ENROLLTRNRS> 
</SIGNUPMSGSRSVl> 
</OFX> 

15.8.3 Activation Example 



-Signon response-> 



<! — Timestamp, 3/07/97,. 8:14:37am — > 

<! — Timestamp, 3/01/97, 7:00:00am — > 
<! — Timestamp, 3/01/97, 7:00:00am--> 



<! --Enrollment response— > 



<! — When Temp Password Expires--> 



After enrollment, Cindy wants to sign up with a biller, presumably found with the directory services, with 
biller ID 415-552-9923 of bill publisher Publisher, Inc. 

15.8.3.1 Activation Request Example 



<OFX> 

<SIGN0NMSGSRQV1> 
<SONRQ> 

<DTCLIENT>1997 030812224 3 
<USERID>cindyid 
<USERPASS>yl234 5 
<LANGUAGE>ENG 
<APPID>OFXAPP 
<APPVER>0201 
</SONRQ> 
< / S I GNONM SGS RQV 1 > 
<SIGNUPMSGSRQV1> 
<ACCTTRNRQ> 

<TRNUID>10002 
<ACCTRQ> 
<SVCADD> 

<PRESACCTTO> 

<BILLPUB>Publisher, Inc. 
<BILLER>4 15-552-9923 



<! — Signon Request — > 

<! — Timestamp, 3/08/97, 12:22:43pm — > 

<! — client's userid--> 

<! — client's temporary password— > 



<! — Activation Request — > 
<! — Activate biller acct - 
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<ACCTID>4128 9343 2324 2314 
<PRESNAMEADDRESS> 

<NAME>Cindy P Williams <! — Name as on biller's statement — > 
<ADDR1>123 Oak St <!— Address as on statement- -> 

<CITY>San Jose 
<STATE>CA 
<POSTALCODE>94111 
<COUNTRY>USA 
<PHONE>40 8-555-232 3 
</PRESNAMEADDRESS> 
<USERID>cindyid 
</PRESACCTTO> 
</SVCADD> 
<SVC>PRESSVC 
</ACCTRQ> 
</ACCTTRNRQ> 
</SIGNUPMSGSRQVl> 
</OFX> 



15.8.3.2 Activation Response Example 



<OFX> 

<SIGNONMSGSRSVl> 
<SONRS> 

<STATUS> 
<CODE>0 

<SEVERITY>INFO 
</STATUS> 

<DTSERVER>199703081814 37 
< LANGUAGE >ENG 
<DTPROFUP>l 9 97030 107 0000 
<DTACCTUP>1 9 97030 107 0000 
</SONRS> 
</SIGNONMSGSRSVl> 
<SIGNUPMSGSRSV1> 
<ACCTTRNRS> 

<TRNUID>10002 
<STATUS> 
<CODE>0 

<SEVERITY>INFO 
</STATUS> 
<ACCTRS> 

<SVCADD> 

<PRESACCTTO> 

<BILLPUB>Publisher, Inc. 
<BILLER>4 15-552-9923 
<ACCTID>4128 9343 2324 2314 
<PRESNAMEADDRESS> 
<NAME>Cindy P Williams 
<ADDR1>123 Oak St 
<CITY>San Jose 
<STATE>CA 
<POSTALCODE>94 1 1 1 
<COUTNRY>USA 
<PHONE>4 08-555-2323 
</PRESNAMEADDRESS> 
<USERID>cindyid 
</PRESACCTTO> 
</SVCADD> 
<SVC>PRESSVC 
</ACCTRS> 
</ACCTTRNRS> 



<! — Signon Response-> 



< ! — Timestamp, 3/07/97, 6:14: 37pm--> 



< ! --Timestamp, 
< ! — Timestamp, 



3/01/97, 
3/01/97, 



7:00:00am — > 
7:00:00am — > 



<! --Enrollment Response— > 
<! --Service Activation Response- 
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</SIGNUPMSGSRSVl> 
</OFX> 

15.8.4 Bill Delivery Examples 
15.8.4.1 Customer Bill Delivery Example 

The customer, Dan North, wants to see his bills since 3/1/97, which is the last time he asked to see his bills. 

15.8.4.1 .1 Customer Bill Delivery Request Example 

<OFX> 

<SIGNONMSGSRQVl> 
<SONRQ> 

<DTCLIENT>19970409090000 <! --Current date 4/9/1997 — > 

<USERID>123-45-6789 <!— Dan North's user id— > 

<USERPASS>Dans Pas sword 
<LANGUAGE>ENG 
<APPID>EndUserApp 
<APPVER>0700 
</SONRQ> 
</SIGNONMSGSRQVl> 
< PRE S DL VMS GS RQ V 1 > 
<PRESLISTTRNRQ> 
<TRNUID>12345 
<PRESLISTRQ> 

<BILLPUB> ABillPublisher 

<DTSTART>19970301000000 < ! — Get Dan's bills since 3/1/97— > 

<INCLUDEDETAIL>Y 
</PRESLISTRQ> 
</ PRESLI STTRNRQ> 
</PRESDLVMSGSRQVl> 
</OFX> 

15.8.4.1 .2 Customer Bill Delivery Response Example 

<OFX> 

<SIGN0NMSGSRSV1> 
<SONRS> 

<STATUS> 
<CODE>0 

<SEVERITY>INFO 
</STATUS> 

<DTSERVER>1 9 9704 0900 1600 
</SONRS> 
</SIGNONMSGSRSVl> 
<PRESDLVMSGSRSV1> 
<PRESLISTTRNRS> 
<TRNUID>12345 
<STATUS> 
<CODE>0 

<SEVERITY>INFO 
</STATUS> 
<PRESLISTRS> 

<BILLPUB>ABillPublisher 

<USERID>123- 45-678 9 

<DTSTART>19970301000000 <!— Same as in request: no data loss— > 

<DTEND>19970409090000 <! —Value for DTSTART next time — > 

<PRESLIST> 

<PRESBILLINFO> 
<FITID>65432 
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<PRESACCTFROM> 

<BILLPUB>ABillPublisher 

<BILLERID>1001 <! — Biller id for Power Inc--> 

<ACCTID>1245678GL7 <! — Dan North's acct with Power Inc — > 

</PRESACCTFROM> 

<REMITT0KEN>12 34 67 8GL7 970501 

<AMTDUE>124.24 <!--Dan North to pay $124.24 — > 

<DTPMTDUE>19970501 <! — by 5/1/97 --> 

<DTBILL>19970401 
<NOT I FYDES IRE D>N 
<STMNTIMAGE> 
<IMAGEURL> 

https : //www . Power . com/bills/apr /dannorth . htm?authtoken=65j 31tfm7 
<DTEXPIRE>1 99704 101200 

<! — Must visit url by 4/10/97 12am — > 

</STMNTIMAGE> 
<PRESDETAILRS> 

<FITID>65432 <!--This links detail to billinfo — > 

<TABLE> 

<TABLENAME>usage 

<TABLETYPE>x_Power_usage 

<! — Power Inc format for usage — > 

<ROW> 

<C>elec <! — Consumable — > 

<C>19970228 <! — Date meter reading start of period-> 

<C>65543 <! — Meter reading at start of period — > 

<C>19970328 <! — Date meter reading end of period — > 

<C>65643 <! — Meter reading at end of period--> 

<C>100 <! --Difference in meter readings--> 

<C>KWH <! — Units — > 

<C>.8934 <! — Rate (price per unit) — > 

<C>89.34 <! — Charge — > 

</ROW> 
<ROW> 



<C>gas 


< ! 


— Consumable — > 




<C>19970226 


<! 


--Date meter reading start of period- 


> 


<C>509843 


<! 


--Meter reading at start of period -- 


> 


<C>19970327 


< ! 


— Date meter reading end of period -- 


> 


<C>510843 


<! 


— Meter reading at end of period — > 




<C>1000 


<! 


--Difference in meter readings — > 




<C>Therms 


<! 


— Units — > 




<C>. 02543 


<! 


--Rate (price per unit) --> 




<C>25. 43 


<! 


--Charge --> 





</ROW> 
</ TABLE > 
<TABLE> 

<TABLENAME>charges 

<TABLETYPE>x- Power-charges 

<ROW> 

<C>75.34 <! — Amount — > 

<C>Previous Balance 3/1/97 

<! --Description — > 

</ROW> 
<ROW> 

<C>75. 34 

<C>Payment Received 3/17/97 - Thank You! 
</R0W> 
<ROW> 

<C>0 

<C>0pen Balance 
</ROW> 
<ROW> 

<C>114 .77 
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<C>Services, Subtotal 
</ROW> 
<ROW> 

<C>9.47 

<OTaxes, 8.25% 
</ROW> 
</TABLE> 
</PRESDETAILRS> 
</PRESBILLINFO> 
<PRESBILLINFO> 
<FITID>65436 
<PRESACCTFROM> 

<BILLPUB>ABillPublisher 

<BILLERID>2021 <!— Biller id of FluteRental, Inc. - 

<ACCTID>8765XY95 <! — Dan North's account number — > 

</PRESACCTFROM> 

<REMITTOKEN>87 65XY95970 42 8 

<AMTDUE>16.21 <! —Total to be paid — > 

<DTPMTDUE>19970428 <! — by 4/28/97 — > 

<DTBILL>19970408 

<NOTI FYDES IRED>N 

<STMNTIMAGE> 

<IMAGEURL> https : //www . FluteRental . com/ 95r s3vlx/bill . asp 
<DTEXPIRE>19970601 <! — Must visit url by 6/1/97 — > 
</STMNTIMAGE> 

<DETAI LAVAI LABLE>N <! — No structured detail exists — > 



</PRESBILLINFO> 
</PRESLIST> 
</PRESLISTRS> 
</PRESLISTTRNRS> 
</PRESDLVMSGSRSVl> 
</OFX> 



15.8-4.2 Bill Delivery for Customer Service Representative 

This example assumes that Dan North calls Power Inc with a question about his power bill. Power's 
customer service representative, Maria Smith, uses a similar application and a similar Open Financial 
Exchange request to see the same bill that Dan sees. 

15.8.4.2.1 Bill Delivery Request Example for a Customer Service Representative 

<OFX> 

<SIGNONMSGSRQVl> 
<SONRQ> 

<DTCLIENT>1 99704 10100000 

<USERID>987-65-4321 <! —Maria Smith's user id — > 

<USERPASS>Marias Password 

<LANGUAGE>ENG 

<APPID>CSRApp 

<APPVER>0500 
</SONRQ> 
</SIGNONMSGS RQV 1 > 
<PRESDLVMSGSRQV1> 
<PRESLISTTRNRQ> 

<TRNUID>23456 

<USERID>123-45-6789 <!— Asks for Dan North's bills — > 

<PRESLISTRQ> 

<BILLPUB> ABillPublisher 

<DTSTART>19970330 <! —Approximate date — > 

<DTEND>1997040410 <! —Approximate date — > 

<NOTIFYWILLING>N 
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<INCLUD£DETAIL>Y 
</PRESLISTRQ> 
</PRESLISTTRNRQ> 
</PRESDLVMSGSRQVl> 
</OFX> 



15.8.4.2.2 Bill Delivery Response Example for a Customer Service Representative 

The response from the server includes the Power Incorporated bill, but not the FluteRental bill. This is 
because the server decides that Maria Smith's credentials are good enough to see Dan North's Power Inc 
bill, but not good enough to see anything else. 

<OFX> 

<SIGNONMSGSRSVl> 
<SONRS> 

<STATUS> 
<CODE>0 

<SEVERITY>INFO 
</STATUS> 

<DTSERVER>1 99704 10101300 
</SONRS> 
</SIGNONMSGSRSVl> 
<PRESDLVMSGSRSV1> 
<PRESLISTTRNRS> 
<TRNUID>23456 
<STATUS> 
<CODE>0 

<SEVERITY>INFO 
</STATUS> 
<PRESLISTRS> 

<BILLPUB>ABillPublisher 

<USERID>123-45-6789 <! — Dan North's userid, so Dan's bill — > 

<DTSTART>19970328 < ! — Same as in request: no data loss— > 

<DTEND>19970409 <!— Same as in request— > 

<PRESLIST> 

<PRESBILLINFO> 
<FITID>65432 
<PRESACCTFROM> 

<BILLPUB>ABill Publisher 

<BILLERID>1001 < ! --Biller id for Power Inc--> 

<ACCTID>1245678GL7 <!— Dan's account with Power Inc— > 

</PRESACCTFROM> 

<REMITTOKEN>1234 67 8GL7 970501 

<AMTDUE>124.24 <!— Dan to pay $124.24 — > 

<DTPMTDUE>19970501 <! — by 5/1/97 — > 

<DTBILL>19970401 
<NOTIFYDESIRED>N 
<STMNTIMAGE> 
<IMAGEURL> 

https : / /www . Power . com/bills/apr/dannorth . htm?authtoken=987ab6gr8y 
<DTEXPIRE>1 99704 111200 

<! — Must visit url by 4/11/97 12am — > 

</STMNTIMAGE> 
<PRESDETAILRS> 
<FITID>65432 
<TABLE> 

<TABLENAME>usage 
<TABLETYPE>x_Power_usage 

<! --Power Inc format for usage — > 

<ROW> 

<C>elec <! — Consumable — > 

<C>19970228 <! — Date meter reading start of period-> 



Open Financial Exchange 



352 



1 1/25/03 
Final Draft 



<C>65543 
<C>19970328 



<! --Meter reading at start of period — > 
<!--Date meter reading end of period--> 
<! --Meter reading at end of period — > 
<! --Difference in meter readings — > 

< ! — Units — > 

<!--Rate (price per unit) — > 

< ! — Charge — > 



<C>65643 
<C>100 



<C>KWH 



<C>.8934 
<C>89.34 



</ROW> 

<ROW> 

<C>gas 
<C>19970226 
<C>509843 
<C>19970327 



<! 
<! 

< ! 
<! 
<! 

< ! 

< ! 
<! 
<! 



•Consumable — > 

■Date meter reading start of period-> 
■Meter reading at start of period — > 
Date meter reading end of period — > 
Meter reading at end of period — > 
■Difference in meter readings — > 
Units — > 

Rate (price per unit)--> 
Charge--> 



<C>510843 
<C>1000 
<C>Therms 
<C>. 02543 
<C>25.43 



</ROW> 
</TABLE> 
<TABLE> 

<TABLENAME>charges 

<TABLE TYPE >x- Power -charges 
<ROW> 

<C>75.34 <i — Amount — > 

<C>Previous Balance 3/1/97 <! — Descripti< 

</ROW> 

<ROW> 

<C>75.34 

<C>Payment Received 3/17/97 - Thank You! 
</ROW> 
<ROW> 

<C>0 

<C>Open Balance 
</ROW> 
<ROW> 

<C>114.77 

<C>Services, Subtotal 
</ROW> 
<ROW> 

<C>9. 47 

<OTaxes, 8.25% 
</ROW> 



</TABLE> 
</PRESDETAILRS> 
</PRESBILLINFO> 



</PRESLIST> 
</PRESLISTRS> 
</PRESLISTTRNRS> 
</PRESDLVMSGSRSVl> 



</OFX> 
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15.8.4.3 Bill Delivery for a Group of Users 

In this example, Realtors Company downloads the phone bills for the employees' office phones by asking 
the bill publisher to see the bills for the group RealtorsEmployees. The composition of the group 
RealtorsEmployees has been agreed upon between Realtors Company and the bill publisher; moreover, the 
bill publisher has agreed to grant Realtors Company access rights to the RealtorsEmployees group. All this 
took place outside of Open Financial Exchange. 

15.8.4.3.1 Bill Delivery Request Example for a Group of Users 

<OFX> 

<SIGNONMSGSRQVl> 
<SONRQ> 

<DTCLIENT>1 99705 151 00000 
<USERID>888-6 6-4 4 44 
<USERPASS>Realtors Pas sword 
<LANGUAGE>ENG 
<APPID>CSRApp 
<APPVER>0500 
</SONRQ> 
</SIGNONMSGSRQVl> 
<PRESDLVMSGSRQV1> 
<PRESLISTTRNRQ> 
<TRNUID>34567 

<GROUPID>RealtorsEmployees 
<PRESLISTRQ> 

<BILLPUB> ABillPublisher 
<DTSTART>1 99704 30 
<NOTIFYWILLING>N 
<INCLUDEDETAIL>Y 
</PRESLISTRQ> 
</PRESLISTTRNRQ> 
</PRESDLVMSGSRQVl> 
</OFX> 



15.8.4.3.2 Bill Delivery Response Example for a Group of Users 

The response, not shown here, will include several bills each marked with its own <USERID>. The only 
bills returned will be the employees' phone bills for their office phones, since those bills are the only ones 
to which Realtor Company has access rights. 

15.8.4.4 Group Account Information Example 

This is an example of a client proxy system that is tracking changes to the accounts of a group of users. 

1 5.8.4.4.1 Group Account Information Request Example 

<OFX> 

<SIGN0NMSGSRQV1> <!— Signon Request-> 

<SONRQ> 

<DTCLIENT>19970307022243 <! —Times tamp, 3/07/97, 2:22:43am— > 

<USERID>AClientProxySystem 

<USERPASS>T23qdfw2 <! — Password of proxy system — > 

< LANG UAG E > E NG 

<APPID>OFXAPP 

<APPVER>0201 



<! — Realtors Company's user id — > 

<! — Asks for Employee's phone bills— > 
<! — since 4/30/1997 — > 
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</SONRQ> 
</SIGNONMSGSRQVl> 

<PRESACCTINF0MSGSRQV1> <! —Group Account Info Request— > 

<PRESGRPACCTINFOTRNRQ> 
<TRNUID>10001 

<GROUPID>AClientProxysCustomers 

<! — Predefined group of customers — > 

<ACCTINFORQ> 

<DTACCTUP>19970104 < ! —Last DTACCTUP received for group— > 

</ACCTINFORQ> 
</PRESGRPACCTINFOTRNRQ> 
</PRESACCTINFOMSGSRQVl> 
</OFX> 

15.8.4.4.2 Group Account Information Response Examples 

<OFX> 

<SIGN0NMSGSRSV1> < ! — Signon Responses 

<SONRS> 

<STATUS> 
<CODE>0 

<SEVERITY>INFO 
</STATUS> 

<DTSERVER>19970307081437 <! —Times tamp, 3/07/97, 8:14:37am— > 

<LANGUAGE>ENG 

<DTPROFUP>19970301070000 < ! --Timestamp, 3/01/97, 7:00:00am— > 

<DTACCTUP>19970301070000 < ! — Timestamp, 3/01/97, 7:00:00am— > 

</S0NRS> 
</SIGNONMSGSRSVl> 

<PRESACCTINF0MSGSRSV1> <! —Group Account Info Response— > 

<PRESGRPACCTINFOTRNRS> 
<TRNUID>10001 
<STATUS> 
<CODE>0 

<SEVERITY>INFO 
</STATUS> 
<ACCTINFORS> 

<DTACCTUP>1997 01220 92 431 
<PRESACCTINFO> 

<PRESACCTFROM> 

<BILLPUB>PUBLISHER, INC . 
<BILLER>4 15-552-9923 
<ACCTID>408-555-4 342-Ml32 

<USERID>bygeorge < ! — User from group with new status— > 

</PRESACCTFROM> 
<SVCSTATUS>ACTIVE 
</PRESACCTINFO> 
< / PRESACCT I NFORS > 
< PRESACCT I N FORS > 

<DTACCTUP>1 997012 3082 4 23 
<PRESACCTINFO> 

<PRESACCTFROM> 

<BILLPUB>PUBLISHER, INC . 
<BILLER>4 15-552 -9923 
<ACCTID>408-555-2341-U421 

<USERID>132-42-5242 <!— User from group with new status— > 

</PRESACCTFROM> 
<SVCSTATUS>REJECTED 

<REASON>ACCOUNT NOT FOUND <!— User supplied account with biller— > 

<! --didn't match biller' s records — > 

</PRESACCTINFO> 
< / P RE S AC CT I N FORS > 
</PRESGRPACCTINFOTRNRS> 
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</PRESACCTINFOMSGSRSVl> 
</OFX> 
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